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Abstract 

Phishing in mobile applications is a relevant threat with 
successful attacks reported in the wild. In such attacks, 
malicious mobile applications masquerade as legitimate 
ones to steal user credentials. In this paper we catego¬ 
rize application phishing attacks in mobile platforms and 
possible countermeasures. We show that personalized 
security indicators can help users to detect phishing at¬ 
tacks and have very little deployment cost. Personalized 
security indicators, however, rely on the user alertness 
to detect phishing attacks. Previous work in the con¬ 
text of website phishing has shown that users tend to ig¬ 
nore the absence of security indicators and fall victim of 
the attacker. Consequently, the research community has 
deemed personalized security indicators as an ineffective 
phishing detection mechanism. 

We evaluate personalized security indicators as a 
phishing detection solution in the context of mobile ap¬ 
plications. We conducted a large-scale user study where 
a significant amount of participants that used personal¬ 
ized security indicators were able to detect phishing. All 
participants that did not use indicators could not detect 
the attack and entered their credentials to a phishing ap¬ 
plication. We found the difference in the attack detection 
ratio to be statistically significant. Personalized security 
indicators can, therefore, help phishing detection in mo¬ 
bile applications and their reputation as an anti-phishing 
mechanism should be reconsidered. 

We also propose a novel protocol to setup personalized 
security indicators under a strong adversarial model and 
provide details on its performance and usability. 


1 Introduction 


Application phishing attacks in mobile platforms occur 
when malicious applications mimic the user interface 
(UI) of legitimate applications to steal user data. Phish¬ 
ing applications have been reported in the wild [ |T0|[34| 


and more sophisticated attacks are described in |12|42) . 

Phishing applications do not exploit system vulnera¬ 
bilities. They use standard system features and leverage 
the user’s incapacity to distinguish the legitimate appli¬ 
cation from a phishing one. Therefore, signature-based 
detection techniques (like the ones used to detect mal¬ 
ware) and security mechanisms on the device (like appli¬ 
cation sandboxing) cannot counter application phishing 
attacks. 

Online services use personalized security indicators to 
aid the user in distinguishing the legitimate website from 
a phishing one (2||37). The personalized security indi¬ 
cator (or “indicator” from now on) is an image that the 
user chooses when he enrolls for the online service. Af¬ 
ter enrollment, the website displays the indicator every 
time the user logs in. The indicator allows the user to au¬ 
thenticate the website and he should enter his credentials 
only if the website displays the correct indicator. 

Mobile applications could also use indicators to miti¬ 
gate application phishing attacks (42) . The user chooses 
the indicator when he installs the application and must 
check that the application shows the correct indicator at 
each login. The indicator is then stored by the applica¬ 
tion and the mobile OS prevents other applications from 
reading it. 

In this paper we start by categorizing application 
phishing attacks in mobile platforms and possible coun¬ 
termeasures. We show that personalized indicators can 
mitigate all the attacks we consider and have little de¬ 
ployment cost. Personalized indicators, however, rely 
on the user to detect phishing attacks by checking the 
presence of the correct indicator. Previous work in the 
context of websites has shown that users tend to ignore 
the absence of indicators (20j[33) . Consequently, the re¬ 
search community deems personalized indicators as an 
ineffective phishing detection mechanism (3[jT^| . 

Because no study has evaluated personalized indica¬ 
tors for mobile platforms, we conducted a large-scale 
user study to verify if personalized indicators can help 
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mitigating application phishing attacks. Over one week, 
221 participants used a banking application we devel¬ 
oped to complete various e-banking tasks. On the last 
day, the application simulated a phishing attack. A sig¬ 
nificant amount of participants that used personalized in¬ 
dicators were able to detect phishing. All participants 
that did not use indicators could not detect the attack and 
entered their credentials to the phishing application. We 
found the difference in the attack detection ratio to be 
statistically significant. Based on these results we con¬ 
clude that personalized indicators can help phishing de¬ 
tection in mobile applications and their reputation as an 
anti-phishing mechanism should be reconsidered. 

We also look at the problem of setting up personalized 
indicators in mobile applications. Previous work @0 
[37}[39]|42) relies on the “trust on first use” (TOFU) as¬ 
sumption and does not account for the possibility that 
the indicator itself is phished during its setup. We con¬ 
sider a stronger attacker model where malicious software 
is present on the device when the user sets up the indica¬ 
tor. We propose a novel protocol to set up indicators se¬ 
curely under such adversary presence. We implemented 
a prototype of the protocol for the Android platform and 
evaluated its performance. We also present the results 
of a small-scale user study with 30 participants on the 
usability of the setup protocol. 

To summarize, in this paper we make the following 
contributions: 

• We analyze application phishing attacks in mobile 
platforms and possible countermeasures. We show 
that personalized indicators are a cost-effective 
means to mitigate application phishing attacks, as¬ 
suming user alertness. 

• We report the results of a large-scale user study 
on the effectiveness of personalized indicators as a 
phishing-detection mechanism. Our results show 
that personalized indicators can significantly im¬ 
prove detection of phishing attacks in mobile appli¬ 
cations. 

• We design and implement a novel protocol to se¬ 
curely set up personalized indicators under a strong 
adversarial model. We have implemented a proto¬ 
type and evaluated its usability with a small-scale 
user study. 

The rest of the paper is organized as follows. In Sec¬ 
tion [2] we discuss application phishing attacks and coun¬ 
termeasures. In Section[3]we describe our user study and 
report its results. We describe the secure setup protocol, 
its implementation and evaluation in Section]?] Section]?] 
reviews related work and Section]?] provides concluding 
remarks. 


2 Phishing Attacks and Countermeasures 

In this section we categorize known application phishing 
attacks in mobile platforms. All attacks are effective on 
Android while one of them also works for iOS. We also 
discuss possible countermeasures and analyze them with 
respect to security, usability and deployment aspects. Ta¬ 
ble [I] provides a summary of phishing attacks and coun¬ 
termeasures. 


2.1 Phishing Attacks 

Similarity attack. The phishing application has a name, 
icon, and UI that are similar or identical to the legitimate 
application. The adversary must induce the user to in¬ 
stall the phishing application in place of the legitimate 
one. Successful similarity attacks have been reported for 
Android |8| 10 [34] and iOS (26). 

Forwarding attack. Another phishing technique is to 
exploit the application forwarding functionality of An¬ 
droid ED A malicious application prompts the user to 
share an event (e.g., a high-score in a game) on a social 
network and shows a button to start the social network 
application. When the user taps the button, the malicious 
application does not launch the social network applica¬ 
tion, but rather displays a phishing screen. The phishing 
screen asks the user to enter the credentials to access his 
account on the social network. Application forwarding is 
a common feature of Android and, therefore, forwarding 
attacks may be difficult for the user to detect. 
Background attack. The phishing application waits in 
the background and uses the ActivityManager of An¬ 
droid, or a side-channel (24) , to monitor other running 
applications. When the user starts the legitimate applica¬ 
tion, the phishing application activates itself to the fore¬ 
ground and displays a phishing screen G3 
Notification attack. The attacker shows a fake notifica¬ 
tion and asks the user to enter his credentials (42) . The 
notification window can be customized by the adversary 
to mimic the appearance of the legitimate application. 
Floating attack. The attacker can leverage the Android 
feature that allows one application to draw an activity on 
top of the application in the foreground. This feature is 
used by applications to always keep a window in the fore¬ 
ground, for example, to display floating sticky notes. A 
phishing application that has the SYSTEM_ALERT.WINDOW 
permission can draw a transparent input field on top of 
the password input field of the legitimate application. 
The UI of the legitimate application remains visible to 
the user that has no means to detect the overlaid input 
field. When the user taps on the password field to enter 
his password, the focus is transferred to the phishing ap¬ 
plication which receives the password input by the user. 
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Marketplace Phishing Detection 

On-device Phishing Prevention 

Name Visual 

similarity similarity 

Limit multi- Application Personal 

tasking name indicator 

attacks 

/ 

/ 

/ 

- - / 

- / / 

/ / / 

/ / / 

/ / / 

similarity attack 
forwarding attack 
background attack 
notification attack 
floating attack 

security 

/ / 

- / / 

false positives/negatives 
reliance on user alertness 

usability 

- 

- - / 

/ / 

/ /! - 

user effort at installation 

user effort at runtime 

restrictions on device functionality 

deployment 

/ / 

/ 1 2 / 2 

/ / - 
/ 

changes to application provider (e.g., bank) 
changes to marketplace 
changes to mobile OS 
changes to application 


Restriction to full-screen applications with constant user interaction (Android Immersive mode) 
2 to run a security check on sideloaded applications 


Table 1: Comparison of mechanisms to prevent application phishing attacks in mobile platforms. 


2.2 Phishing Countermeasures 

None of the attacks we discuss exploit OS vulnerabili¬ 
ties, but they rather use standard Android features and 
APIs. Therefore, security mechanisms on the device 
(e.g., sandboxing or permission-based access control) 
cannot prevent such attacks. Similarly, security screen¬ 
ing run by the marketplace operator (e.g., the Google 
Bouncer systeirQ may not detect phishing applications. 
Security screening relies on signature-based malware de¬ 
tection techniques that look for specific system calls pat¬ 
terns and requested permissions. Phishing applications 
do not exhibit malicious code patterns, nor they require 
suspicious permissions. 

Similar to website phishing, application phishing pre¬ 
vention requires tailored security mechanisms. We now 
describe possible countermeasures and categorize them 
in terms of security, usability and deployment. 

Name similarity. Marketplace operators can attempt 
to detect similarity attacks by searching for applications 
with similar names or icons. Since many legitimate 
applications have similar names or icons (for example, 
banking applications for the same bank in different coun¬ 
tries), this approach would produce a significant amount 
of false positives. Detecting phishing applications at the 
marketplace does not rely on the user alertness nor does 
it change the user experience. Checking for phishing ap¬ 
plications downloaded from the web or from third-party 
marketplaces (sideloading) requires changes to the mo¬ 

1 http://googlemobile.blogspot.ch/2012/02/android-and- 

security.html 


bile OS. In particular, the mobile OS should query the 
marketplace operator for applications that have the same 
name or icon of the application being installed. 

Visual similarity. The marketplace operator can attempt 
to mitigate background or forwarding attacks by search¬ 
ing for applications with similar UIs and, in particular, 
similar login screens. Since many applications share a 
similar login screen, detection based on similar UIs is 
likely to cause false positives. If detection is based on 
matching UIs, phishing applications that use a slightly 
modified version of the legitimate application UI, may 
go unnoticed. Finding an effective tradeoff (a similarity 
threshold) may be a challenging task and requires further 
investigation. 

Limit multi-tasking. An approach to counter back¬ 
ground or floating attacks is to limit multi-tasking on 
the device. The legitimate application can trigger a re¬ 
stricted mode of operation where no third-party applica¬ 
tions can activate to the foreground. Multi-tasking can 
be re-enabled once the user explicitly terminates the ap¬ 
plication. Activation to the foreground can always be 
allowed for system services, in order to receive phone 
calls or SMS messages. This approach does not rely on 
the user alertness but it requires changes to the OS (to 
toggle multi-tasking on and off) and hinders the user ex¬ 
perience. For example, the user cannot receive events 
from third-party applications (e.g., social network notifi¬ 
cations) while he is interacting with an application that 
requested multi-tasking to be disabled. 

Application name. The mobile OS can show a status bar 
with the name of the application in the foreground (35) . 
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Phishing detection with this approach is effective only if 
the user is alert and the phishing application has a name 
and icon that are noticeably different from the ones of 
the legitimate application. This technique cannot ad¬ 
dress name similarity attacks. Furthermore, the status 
bar reduces the screen estate for applications that run in 
full-screen mode. An approach where the status bar ap¬ 
pears only when the user interacts with the application is 
only practical for application with low interaction, such 
as video players (Android Lean Back mode). For appli¬ 
cations that require constant interaction, such as games 
(Android Immersive mode), forcing a visible status bar 
would hinder the user experience. 

Personalized indicator. When the application is in¬ 
stalled, the user chooses an image from his photogallery. 
When the application asks the user for his credentials, it 
displays the image chosen by the user at installation time. 
An alert user can detect a phishing attack if the applica¬ 
tion asking for his credentials does not show the correct 
image. The mobile OS prevents other applications from 
reading the indicator of a particular application (through 
application-specific storage). This countermeasure can 
also mitigate floating attacks. In particular, the legiti¬ 
mate application can check if it is running in the fore¬ 
ground and remove the image when it detects that it has 
lost focu^] Personal indicators can be easily deployed 
as they do not require changes to the OS or to the mar¬ 
ketplace. However, they demand extra user effort when 
the application is installed (because the user must choose 
the indicator) and used (because the user must check that 
the application displays the correct indicator). 

Summary. Our analysis is summarized in Table [T] All 
the countermeasures we discuss incur trade-offs in at¬ 
tack prevention, usability, functionality and deployment. 
Personalized indicators can address all the attacks we 
consider and are easy to deploy as they do not require 
changes on the device or at the marketplace. Personal¬ 
ized indicators, however, rely on the user to detect phish¬ 
ing attacks. Previous work (20[|33) has shown that most 
users ignore the absence of indicators when logging into 
an online banking service from a desktop web browser. 
These results contributed to the reputation of personal¬ 
ized indicators as a weak mechanism to detect phishing. 
Because personalized indicators were never tested in the 
context of mobile platforms, we decided to verify their 
effectiveness as a detection mechanism for application 
phishing attacks. We conducted a large-scale user study 
and report its results in the next section. 


2 An application can detect that it loses focus by overriding the 
method onWindowFocusChangedQ. 


3 User Study 

The goal of our user study was to evaluate the effective¬ 
ness of personalized indicators as a phishing-detection 
mechanism for mobile applications. We focused on a 
mobile banking scenario and implemented an applica¬ 
tion that allowed uses to carry out e-banking tasks for 
a fictional bank called SecBANK. We asked partici¬ 
pants to install the SecBANK application on their phones 
and provided them with login credentials (username and 
password) to access their accounts at SecBANK. We as¬ 
signed each participant to either a control group that used 
a SecBANK application without personalized indicators 
(Figure[la]), or one of three experimental groups that used 
the SecBANK application with personalized indicators 
(Figure [lb]). The experimental groups differed in the 
type of phishing attack. The user study lasted one week. 
During the first three days, participants carried out one 
e-banking task per day to familiarize with the applica¬ 
tion and its login mechanism (with or without personal¬ 
ized indicators, depending on the group to which a par¬ 
ticipant was assigned). On the seventh day, participants 
were asked to perform a fourth e-banking task and, at this 
time, the application simulated a background phishing 
attack. We recorded whether or not participants entered 
their credentials while under attack. 

We notified the ethical board of our institution which 
reviewed and approved our user-study protocol. 

3.1 Procedure 

Recruitment and Group Assignment. We recruited 
participants through an email sent to all people with an 
account at our institute (students, faculty and university 
staff). The study was advertised as a user study to “test 
the usability of a mobile banking application” without 
details on the real purpose of our design. We offered a 
compensation of 20$ to all participants who would com¬ 
plete the pre-test questionnaire. 

We received 465 emails of potential participants to 
whom we replied with a link to an online pre-test ques¬ 
tionnaire designed to collect email addresses and demo¬ 
graphic information. 301 participants filled in the pre¬ 
test questionnaire. We assigned them to one of the fol¬ 
lowing four groups in a round-robin fashion: 

• Control Group (A): The application used by this 
group did not use personalized indicators. On the 
last day of the user study, the application simulated 
a background attack where the phishing application 
showed a clone of the SecBANK login screen. 

• Missing-Image Group (B): The application used 
by this group supported personalized indicators. On 
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Forgotten Password? 
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Login 


Forgotten Password? 
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similar to the ones provided by 12|37) to the users of their 
e-banking platforms. 276 participants visited the web¬ 
pages and installed the SecBANK application on their 
devices. 

After the installation, the SecBANK application for 
groups B, C, and D showed explanatory overlays to guide 
participants in choosing a personalized indicator from 
their photogallery. 

Tasks. The study lasted one week. Participants where 
asked to perform four e-banking tasks on days 1, 2, 3, 
and 7. We sent instructions to complete each task via 
email and asked participants to complete the task within 
24 hours. The tasks were the followings: 


Figure 1: (a) SecBANK application for the control 

group. The application did not use personalized indica¬ 
tors. (b) SecBANK application for the three experimen¬ 
tal groups. The application displayed the personalized 
indicators chosen by the user on the login screen. (In this 
example the user chose the Mona Lisa.) 


• Task 1 (Day 1): Transfer 200$ to “Anna Smith”. 

• Task 2 (Day 2): Download the bank statement from 
the “Account Overview” tab. 

• Task 3 (Day 3): Activate the credit card from the 
“Cards” tab. 


the last day of the user study, the application simu¬ 
lated a background attack where the phishing appli¬ 
cation showed the SecBANK login screen without 
the indicator (Figure [2a|. 

• Random-Image Group (C): The application used 
by this group supported personalized indicators. On 
the last day of the user study, the application simu¬ 
lated a background attack where the phishing ap¬ 
plication showed the SecBANK login screen with 
a photo taken from the local photogallery that was 
different from the indicator chosen by the user (Fig¬ 
ure [2b]). 

• Maintenance Group (D): The application used by 
this group supported personalized indicators. On 
the last day of the user study, the application simu¬ 
lated a background attack where the phishing appli¬ 
cation showed the SecBANK login with an “under 
maintenance” notification in place of the indicator 
chosen by the user (Figure [2c]). 

We sent an email to all participants who completed 
the pre-test questionnaire with a link to a webpage from 
which they could download and install the SecBANK ap¬ 
plication. Participants in the Control Group (A) were 
directed to a webpage where we only explained how to 
download and install the application. Participants in ex¬ 
perimental groups B, C, and D were directed to a web¬ 
page that also explained the concept of personalized in¬ 
dicators. The webpage advised that participants should 
not enter their login credentials if the application were 
not showing the correct indicator. The instructions were 


• Task 4 (Day 7): Transfer 100$ to “George White”. 

The goal of tasks 1-3 was to help participants to be¬ 
come familiar with the SecBANK application. 

Instructions to perform task 4 were sent four days 
after (including a week-end) the completion of task 3. 
During this last task, the application simulated a back¬ 
ground attack against participants of all groups. Partic¬ 
ipants in the Control Group (A) saw a login screen that 
matched the one of their SecBANK application. Partici¬ 
pants in the Missing-Image Group (B) saw the SecBANK 
login screen without any personalized indicator (see Fig¬ 
ure [2a]). Participants in the Random-Image Group (C) 
saw the SecBANK login screen with a random image 
from their photogallery (e.g., the Tower Bridge as shown 
in Figure [2b]). Finally, participants in the Maintenance 
Group (D) saw a message explaining that due to tech¬ 
nical problems the indicator could not be displayed (see 
Figure [2c]). 

3.2 Results 

Out of 276 participants that installed the application, 221 
completed all tasks. We provide their demographics and 
other information collected during the pre-test question¬ 
naire in Table [2] The majority of the participants were 
male (68%) and thirty years old or younger (94%). Most 
participants used their smartphone to read emails (97%) 
and access social networks (99%). Slightly less than half 
of the participants (44%) used their smartphones for mo¬ 
bile banking. 

The 221 participants that completed all tasks were dis¬ 
tributed as follows: 56 in the Control Group (A), 55 in 
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Figure 2: (a) Missing-Image attack: The application does not show the indicator chosen by the user, (b) Random- 
Image attack: The application shows a random image from the local photogallery (in this case the Tower Bridge of 
London), (c) Maintenance attack: The application shows a message explaining that the indicator cannot be displayed 
due to technical reasons. 


Gender 

Male 

150 (68%) 

Female 

71 (32%) 

Age 

Up to 20 

43 (20%) 

21-30 

164 (74%) 

31-40 

9 (4%) 

41-50 

3 (1%) 

51-60 

0 (0.00%) 

Over 60 

2(1%) 

Use smartphone to read emails 

Yes 

214 (97%) 

No 

7 (3%) 

Use smartphone for social networks 

Yes 

218 (99%) 

No 

3 (1%) 

Use smartphone for e-banking 

Yes 

97 (44%) 

No 

124 (56%) 


Table 2: Demographic information of the 221 partici¬ 
pants that completed all tasks. 

the Missing-Image Group (B), 56 in the Random-Image 
Group (C), and the remaining 54 in the Maintenance 
Group (D^] 

Indicator Effectiveness. Table [3] shows the percentage 
of participants that detected the phishing attack during 

3 We note that, by chance, the participants that completed all tasks 
were almost evenly distributed among the four groups. 



Phishing attack 
not detected 

Phishing attack 
detected 

Control Group 

56 (100%) 

0 (0%) 

Missing-Image 

Group 

25 (45%) 

30 (55%) 

Random-Image 

Group 

33 (59%) 

23 (41%) 

Maintenance 

Group 

25 (46%) 

29 (54%) 


Table 3: Detection rate of the phishing attack in each 
group. 


task 4. None out of the 56 participants in the Control 
Group (A) detected the phishing attack (i.e., all partici¬ 
pants entered their login credentials to the phishing ap¬ 
plication). 82 out of the 165 participants in groups B, C, 
and D detected the phishing attack and did not enter their 
login credentials. 

To analyze the statistical significance of these results 
we used the following null hypothesis: “there will be no 
difference in phishing detection between users that use 
personalized indicators and users that do not use person¬ 
alized indicators”. A chi-squared test showed that the 
difference was statistically significant (^ 2 (3 ,N = 221) = 
46.96,/? < 0.05), thus the null hypothesis can be rejected. 
We concluded that, in our user study, personalized in¬ 
dicators improved the detection of application phishing 
attacks in mobile platforms. 
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Difference Between Attacks. A closer look at the per¬ 
formance of participants in groups B, C, and D reveals 
that: 25 out of 55 participants in the Missing-Image 
Group (B), 33 out of 56 participants in the Random- 
Image Group (C), and 25 out of 54 participants in the 
Maintenance Group (D), detected the phishing attack. 

To analyze the detection rates of the different attack 
types we used the following null hypothesis: “partici¬ 
pants will equally detect the three phishing attacks we 
tested”. A chi-squared test showed no statistical signifi¬ 
cance, thus we fail to reject the null hypothesis. We con¬ 
cluded that in our test setup the three attacks were equally 
detected. 

Other Factors. We further analyzed the collected data 
to understand if there were any correlation between the 
ability to detecting phishing and gender, age, smartphone 
display size or familiarity with mobile banking, respec¬ 
tively. We did not find any statistical significance for any 
of the factors we considered. Table [4] provides the result 
break-down. 

Finally, we could not find any correlation between the 
ability to detect phishing and the time participants spent 
setting up the personalized indicator or logging in, re¬ 
spectively. The mean time spent setting up the indicator 
for participants that detected the phishing attack was 43s 
(±28s); the mean time for participants that did not detect 
the phishing attack was 46s (d=28s). 

The mean time spent on the login screen for partici¬ 
pants that detected the phishing attack was 18s (±14s); 
the mean time for participants that did not detect the 
phishing attack was 14s (±10s). The distribution of the 
times spent while setting up the indicator and while log¬ 
ging in are shown in Figure [3a] and Figure [3b] respec¬ 
tively. 

We could not find any correlation between the time 
spent setting up the indicator and the detection of a phish¬ 
ing attack. Nonetheless, our results show that partic¬ 
ipants that detected the phishing attack did not spend 
more time on the login screen than participants that did 
not detect phishing. Our results show, therefore, that 
phishing attacks can be quickly detected by using per¬ 
sonalized indicators. 


3.3 Post-test questionnaire 

We invited participants that completed all tasks to fill- 
in a post-test questionnaire. Participants of all groups 
answered items related to their concerns about malicious 
software on their smartphones and on the secrecy of their 
passwords, both for email and e-banking. Figure[4]shows 
participant answers on 5-point Likert-scales. 33% of the 
participants were not concerned, 21% had neutral feel¬ 
ings, and 46% were concerned about malicious software 
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Figure 3: Distribution of the time spent by participants 
setting up the personalized indicator (a) and logging into 
the SecBANK application (b). 


on their smartphones (Ql). Most participants reported 
that they were concerned about password secrecy (72% 
for their e-banking passwords (Q2) and 70% for their 
email passwords (Q3)). Participants were more con¬ 
cerned (66% agrees or strongly agrees) about the secrecy 
of their e-banking password than about the secrecy of 
their email passwords (Q4). 

Participants in groups B, C, and D answered additional 
questions about personalized indicators. Only 19% of 
the participants were familiar with personalized indica¬ 
tor prior to this study. 69% of the participants reported 
that they checked the presence of the indicator at each 
log in (Q5). 67% of the participants found personalized 
indicators user-friendly (Q6), and 51% of them would 
use personalized indicators in other application scenarios 
(Q7). Appendix [Ajprovides the full text of items Q1-Q7. 

We asked participants of the experimental groups if 
they had noticed anything unusual when logging in to 
complete task 4. To those participants that gave a pos¬ 
itive answer we also asked if they logged in and why. 
23% of the participants did not notice anything unusual, 
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Phishing attack 
not detected 

Phishing attack 
detected 

Gender 

Male 

54 (48%) 

59 (52%) 

Female 

28 (56%) 

23 (44%) 

Age 

Up to 20 

20 (57%) 

15 (43%) 

21-30 

61 (52%) 

57 (48%) 

31-40 

1 (14%) 

6 (86%) 

41-50 

1 (33%) 

2 (67%) 

51-60 

0 (0%) 

0 (0%) 

Over 60 

0 (0%) 

2 (100%) 

Use smartphone for e-banking 

Yes 

35 (46%) 

41 (54%) 

No 

48 (54%) 

41 (46%) 

Smartphone display size (diagonal) 

up to 4in 

20 (42%) 

28 (58%) 

from 4in to 4.5in 

54 (55%) 

44 (45%) 

from 4.6in to 5in 

9 (47%) 

10 (53%) 


Table 4: Detection rate of the phishing attack in rela¬ 
tion to gender, age, familiarity with mobile banking, and 
smartphone display size. 


while 23% did not remember. 54% of the participants 
noticed something was wrong with the SecBANK appli¬ 
cation while they were logging in. 36% of them reported 
that they logged in anyway. In the following section, we 
discuss the reasons why users logged in despite noticing 
something unusual in the SecBANK login screen. 

3.4 Discussion 



100 50 0 50 100 

Percentage 

Response ^Strongly disagree Disagree Neither agree nor disagreeHAgreeHstrongly agree 


Figure 4: Answers to the post-test questionnaire. Items 
Q1-Q4 were answered by all participants. Items Q5-Q7 
were answered only by participants in the experimental 
groups (B, C, and D). Percentages on the left side in¬ 
clude participants that answered “Strongly disagree” or 
“Disagree”. Percentages in the middle account for partic¬ 
ipants that answered “Nor agree, nor disagree”. Percent¬ 
ages on the right side include participants that answered 
“Agree” or “Strongly agree”. 


“I knew this was a test product so there could 
not possibly be malware for it already. I just 
thought maybe you guys had some difficulties 
going on.” 

From the answers we could assume that the effective¬ 
ness of personalized indicators to detect phishing in a 
real-life scenario may be higher that the one we have re¬ 
ported. 

Nevertheless, we also received answers such as: 


Roughly half of the participants that used personalized 
indicators detected the phishing attack and did not enter 
their credentials to the phishing application. While many 
participants still fell victim of the attack, our user study 
shows a significant improvement compared to previous 
studies in the context of websites (20||33) . We conclude 
that personalized indicators empower alert users to detect 
phishing attacks in mobile applications. Furthermore, the 
deployment of personalized indicators incurs no cost to 
the marketplace operator or to the OS developer, and in¬ 
curs very little cost to the application provider. 

The post-test questionnaire revealed that some partic¬ 
ipants entered their credentials even though they noticed 
that the indicator was missing. We asked the reason for 
their behaviour and we report some answers (redacted to 
correct grammatical errors): 

“Because it is a test and I had nothing to lose 

or hide.” 


“I thought it was a problem of the app [...] 
as it happens sometimes in Safari or other 
browsers.” 

“I thought it was a temporary bug” 

This shows that when it comes to IT-systems, users are 
expecting errors and bugs and therefore they are prone 
to fall for attacks that leverage the unreliable view that 
people have about computer products. 

Finally, we discuss a few hypotheses to answer the 
question of what makes personalized indicators more ef¬ 
fective in the context of mobile applications compared to 
that of desktop environment. Mobile user interfaces are 
considerably simpler than the ones of desktop websites. 
As the user focus is limited to a few visual elements (D, 
personalized indicators could be more salient in mobile 
application UIs. The usage patterns of mobile applica¬ 
tions may also be different from those of websites. 
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Out-of-band Channel 



Figure 5: System model overview. Each application run¬ 
ning on the smartphone is sandboxed and cannot access 
the memory or storage of other applications. Applica¬ 
tions are installed from the marketplace or via sideload¬ 
ing. The bank has an out-of-band channel (e.g., regular 
mail) to its customers. Our protocol adds two compo¬ 
nents to the platform TCB (shown in gray). The Broker 
can measure installed applications and has a UI to receive 
user inputs. A Secure Attention Sequence (SAS) is used 
to start the Broker. 

An interesting direction for future work is to study 
how to display personalized indicators to improve phish¬ 
ing detection. For example, indicator position and size 
within the screen estate may change the effectiveness of 
indicators. Evaluating different types of indicators (e.g., 
interactive indicators, personalized UIs, etc.) is another 
direction for future work. 

4 Secure Setup of Application Indicators 

So far we have presented evidence that personalized in¬ 
dicators can help users to detect application phishing at¬ 
tacks. In this section we focus on the setup of personal¬ 
ized indicators and propose a secure protocol to bootstrap 
indicators in mobile platforms. 

Setup of indicators in previous research proposals |6] 
[39||42| and deployed systems (2j[37) relies on the “trust 
on first use” (TOFU) assumption. The indicator setup 
happens the first time the user registers for an online ser¬ 
vice (2}|6|[37j|39) or starts the application (42), assuming 
that the adversary is not present at this time. Otherwise, 
if the indicator is phished during its setup, malicious soft¬ 
ware can later on masquerade as the legitimate applica¬ 
tion. 

In the rest of this section we propose a protocol to 


setup indicators that does not rely on the TOFU assump¬ 
tion and, therefore, can withstand phishing attacks when 
the user chooses the indicator. As a use case, we con¬ 
sider a mobile banking scenario similar to the one of Sec¬ 
tion [3j and consider an application that supports indica¬ 
tors to improve phishing detection. We start by detailing 
the system and adversarial model we consider. Later on, 
we describe the indicator setup protocol and present an 
implementation for the Android platform. Finally, we 
show the results of both performance and usability study. 

4.1 System and Adversary Model 

Figure [5] illustrates the system model we consider. (Gray 
components are part of our solution and are detailed be¬ 
low.) Mobile applications run on top of an OS that, to¬ 
gether with the underlying hardware, constitute the de¬ 
vice TCB. The TCB guarantees that a malicious applica¬ 
tion cannot tamper with the execution of another appli¬ 
cation (isolated execution) or read its data (application- 
specific storage). The application active in foreground 
controls the screen and receives user inputs. The TCB 
enforces that applications running in the background do 
not intercept user inputs intended for the foreground ap¬ 
plication and cannot capture its output (user interaction 
isolation). 

Since we consider a mobile banking scenario, we as¬ 
sume the existence an out-of-band-channel between the 
bank (i.e., the application provider) and the user. An ex¬ 
ample of this channel is the (regular) mail system rou¬ 
tinely used by banks as a secure and authentic channel 
to transfer PINs and other credentials to their customers. 
As currently used to reset forgotten passwords, emails 
can also be used as an alternative out-of-band channel. 

The goal of the adversary is to phish the indicator that 
the user chooses for the banking application. We assume 
that the user has previously installed, either from the 
marketplace or via sideloading, a malicious application 
on his smartphone. Leveraging the malicious application 
on the user’s phone, the adversary can launch any of the 
attacks presented in Section [TT] However, the adversary 
cannot compromise the device TCB or the out-of-band 
channel between the bank and the user. 

4.2 Secure Indicator Setup Protocol 

Setting up an indicator in the presence of malicious soft¬ 
ware, requires the user to identify the banking applica¬ 
tion for which he is choosing the indicator. A similarity 
attack to phish the indicator at setup time may be hard 
for the user to detect. Similarly, the marketplace opera¬ 
tor may fail to identify phishing applications and block 
their distribution (see Section [2). We argue that no party 
but the bank can attest the validity of the banking appli- 
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cation for which the user is about to choose the indicator. 
For this reason, our protocol relies on a trusted compo¬ 
nent of the mobile platform that, together with the bank, 
attests the validity of the banking application installed on 
the device. 

In particular, the trusted component and the bank es¬ 
tablish an authentic channel to attest the application. If 
attestation is successful, the trusted component provides 
the application with a PIN known by the user. The user 
can identify the legitimate application, if it shows the cor¬ 
rect PIN. 

Figure [5] shows in gray the components that we add 
to the device TCB. A system component that we call the 
Broker can measure applications (e.g., compute a hash 
of the application binary and its configuration files) in¬ 
stalled on the device and has a UI to receive user inputs. 
The mobile OS is also enhanced with a Secure Attention 
Sequence (SAS), which is a common approach to start a 


particular software component of a TCB 


>proac n to s 
|13|23|28f 


We 


implement the SAS operation as two repeated presses of 
the home button and we use it to start the Broker. When 
the Broker is running, the mobile OS ensures that no 
background application can activate to the foreground. 

The bank and the Broker establish an authentic chan¬ 
nel using the out-of-band channel between the bank and 
the user. The bank sends a measurement of the legiti¬ 
mate banking application over the authentic channel, so 
that the Broker can compare it with the measurement of 
the banking application installed on the device. If the two 
measurements match, the Broker transfers to the banking 
application a PIN known by the user. The banking ap¬ 
plication shows the PIN to the user who can, therefore, 
identify the legitimate banking application. 

Figure [6] illustrates the steps to securely setup a per¬ 
sonalized indicator. Here we explain them in detail. 


1. The bank uses the out-of-band channel (e.g., regular 
mail) to send a PIN to the user. 

2. The user installs the application, downloading it 
from the marketplace. When the installation com¬ 
pletes, the user performs the SAS operation to start 
the Broker. While the Broker is running, the mobile 
OS prevents third-party applications from activating 
to the foreground. 

3. The user inputs the PIN to the Broker. 

4. The Broker and the bank use the PIN to run a Pass¬ 
word Authenticated Key Exchange (PAKE) proto- 
col [[18) and establish a shared key. 

4 A popular SAS is the “ctrl-alt-del” sequence in Windows systems 
which generates a non-maskable interrupt that starts the user-logon pro¬ 
cess. 


5. The bank sends the measurement of the legitimate 
banking application to the Broker. The measure¬ 
ment can be the hash of the application installation 
package. The message is authenticated using the 
key established during the previous step. 

6. The Broker verifies the authenticity of the received 
message, measures the banking application on the 
device, and checks its measurement against the ref¬ 
erence value received from the bank. 

7. If the two measurements are identical, the Broker 
securely transfers the PIN to the banking applica¬ 
tion (e.g., writes the PIN to the application-specific 
storage). Otherwise the Broker aborts the protocol 
and notifies the user. 

8. The Broker starts the banking application and the 
mobile OS restores the functionality that allows 
background applications to activate to the fore¬ 
ground. The banking application displays the PIN 
which serves as a confirmation to the user that the 
application in foreground is the legitimate banking 
application. 

9. The user identifies the application in foreground as 
the legitimate banking application if it displays the 
same PIN that the user has received from the bank. 
At this point, the user can choose a personalized in¬ 
dicator for the banking application. 

Security Analysis. Our protocol relies on the user at¬ 
tention when setting up the indicator. At the beginning 
of the setup protocol, the user must input the PIN only 
after performing the SAS operation. At the end of the 
protocol, the user must choose an indicator only if the 
application in foreground displays the same PIN that the 
user has received from the bank. 

The SAS operation and the device TCB guarantee that 
no information is leaked when the user inputs the PIN to 
the Broker. In particular, no malicious application can 
masquerade as the Broker to phish the PIN. The PIN 
is used as a one-time password to derive a key through 
the PAKE protocol. The derived key is only used to au¬ 
thenticate one message (from the bank to the Broker). 
The security properties of the PAKE protocol guarantee 
that, given a transcript of the protocol, the adversary can 
neither learn the PIN, nor brute-force the set of possible 
PINs (25). 

The application-specific storage functionality, pro¬ 
vided by the mobile OS, guarantees that the PIN received 
by the banking application can not be read by other ap¬ 
plications. 

A phishing application on the device will not receive 
the PIN from the Broker because its measurement dif¬ 
fers from the one of the legitimate banking application. 
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Figure 6: The personalized indicator setup protocol. The 
user performs an SAS operation to start the Broker and 
enters the PIN. The Broker verifies the installed banking 
application with the help of the bank. If the installed 
application is the legitimate one, the Broker starts it and 
the user can choose a custom indicator. 

The adversary cannot impersonate the bank to the Broker 
without knowledge of either the PIN or the key derived 
through the PAKE protocol. 

4.3 Implementation 

We build a prototype of our setup protocol for the An¬ 
droid platform. We use a Samsung Galaxy S3 and de¬ 
velop against the CyanogenMod Android OS (version 
4.3 JellyBean). Cryptographic operations are based on 
the Bouncy Castle library (2TJ Message authentication 
uses HMAC-SHA256 with a 128-bit key. The bank’s 
server is implemented in Python, using the CherryPy 
Web Framework and SQLite. Client-server communi¬ 
cation works over a standard HTTP channel using mes¬ 
sages in the JSON standard format. Our implementation 
adds two Java files, to implement the Broker as a privi¬ 
leged application, and modifies four system Java files. A 
total of 652 lines of code were added to the system TCB. 

We add an extra tag (<secureapk>) to the Android 
Manifest file of the banking application. The tag con¬ 
tains two fields indicating a URL and an application han¬ 
dle. The Broker uses the URL to contact the application 
provider (i.e., the bank) and the handle to identify the 
application to attest. When the banking application is in¬ 
stalled, the PackageParser of the Android OS reads the 
extra information in the <secreapk> tag and stores it for 
later use. 


TCB increment 

652 LoC 

Communication overhead 

705 bytes 

Execution time (WiFi) 
Execution time (3G) 
Execution time (Edge) 

421ms (±21ms) 
2042ms (±234ms) 
2957ms (±303ms) 


Table 5: Evaluation summary for the personalized indi¬ 
cator setup prototype. 

We assign the SAS operation to a double-tap on the 
home button. The SAS operation unconditionally starts 
the Broker that asks the user to enter the PIN received 
from the bank (see Figure [7a]). In our implementation, 
the bank sends to the user a 5-digits PIN (e.g., “80547”) 
and a service tag. The service tag contains an appli¬ 
cation handle used by the Broker to search through the 
registered handles and to identify the application to at¬ 
test. The service tag also contains a user ID, sent to the 
bank by the Broker, to retrieve the correct PIN from its 
database. An example of a service tag is “bank:johndoe”, 
where “bank” is the application handle and “johndoe” is 
the user ID. After the user has input the service tag and 
the PIN, the Broker uses the handle to identify the ap¬ 
plication to attest. At this time the Broker also fetches 
the URL stored by the PackageParser, to contact the 
bank’s server. 

We use SPEKE Jl8| as an instantiation of the key es¬ 
tablishment protocol. SPEKE uses 4 messages, includ¬ 
ing a key confirmation step. The first SPEKE message 
sent by the Broker also contains the user ID that al¬ 
lows the bank’s server to select the correct PIN from 
its database. The server uses the key established via the 
PAKE protocol to compute a MAC over the hash of the 
legitimate application. Both the hash and the authentica¬ 
tion tag are sent to the Broker. The Broker verifies the 
authentication tag, hashes the installed application, and 
compares the hash computed locally with the received 
one. If the two hashes match, the Broker writes the PIN 
to the application’s folder so that it can only be read by 
that application. Otherwise, the Broker aborts and noti¬ 
fies the user. 

Figure [7b] shows the banking application started by the 
Broker. The user is asked to compare the displayed PIN 
with the one received via mail and choose a personalized 
indicator. 

Evaluation. We evaluate the setup protocol using a 
a sample banking application of 264KB. Client-server 
communication overhead totals to 705 bytes, of which 
641 bytes account for the SPEKE protocol. (Commu¬ 
nication overhead is independent of the size of the ap¬ 
plication.) We test the protocol over a WiFi connection 
(hosting the server in a remote location, i.e., not on a lo- 
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Broker 


SecBANK 


cator while under attack. 


Service-tag: bankijohndoe 
Token: 80547 


Launch Application 


(a) 


Please check the following Token 
with the one received by mail 


80547 



Customize Indicator 



(b) 


Figure 7: (a) Screenshot of the Broker prototype. The 
user inputs the service tag and the PIN received by the 
bank, (b) Banking application started by the Broker. The 
user must verify that the PIN displayed matches the one 
received by the bank. The application shows the images 
in the local photogallery and the user can select one as 
the indicator. 


cal network), as well as over 3G and EDGE cellular data 
connections. Table [5] summarizes the evaluation in terms 
of added lines of code, communication overhead, and ex¬ 
ecution time. We note that hashing the banking applica¬ 
tion takes 25ms on average, with a standard deviation of 
2ms. The time to hash an application increases linearly 
with the size of the application and remains lower than 
the network delay for applications up to 100MB. 

4.4 Usability 

We run a small-scale user study to evaluate the usability 
of our setup protocol. In particular, our goal was to un¬ 
derstand how easy it is for users to setup indicators by 
following written instructions, like the ones a bank cus¬ 
tomer would receive from his bank. We also wanted to 
verify how attentive users are when comparing the PIN 
shown by the application with the one received from the 
bank. 

We invited participants to our lab and asked them to 
carry out the set up protocol as if they were customers of 
a bank that uses indicators in its application. We pro¬ 
vided participants with a phone and a letter from the 
bank with instructions on how to setup the indicator. 
We assigned participants to three different groups. One 
group carried out the set up protocol in benign settings. 
For the remaining two groups, we simulated variants of 
a background attack at the time when the banking ap¬ 
plication displays the PIN (step 8 of the setup proto¬ 
col). We recorded whether participants pressed the “Cus¬ 
tomize Indicator” button and chose a personalized indi- 


Procedure. Recruitment and Group Assignment. We 
advertised the study as a user study “to evaluate the us¬ 
ability of a setup protocol for an e-banking application”. 
Participants were asked to come to our lab and setup the 
application on a smartphone that we provided. We in¬ 
formed participants that we would not collect any per¬ 
sonal information and offered a compensation of 20$. 

We selected 30 participants and assigned them to one 
of three groups in a round-robin fashion. (None of these 
participants were involved in the user study of Section[3]) 
The difference among the groups was the PIN shown 
by the banking application right before participants were 
asked to choose a personalized indicator. Group A par¬ 
ticipants were shown the same PIN that appeared on the 
letter from the bank. Group B participants were shown a 
random PIN. Group C participants where shown no PIN. 

Participants of group A reflected the user experience 
of the setup protocol under no attack. Participants of 
groups B and C reflected the user experience of the setup 
protocol under a background attack. 

Experiment. The experiment started with a pre-test 
questionnaire to collect demographic information. After 
the questionnaire, participants were given a smartphone 
and a letter from a fictitious bank with instructions to 
setup the indicator. The letter included a 5-digit PIN and 
a service tag to be used during the setup protocol. The 
procedure was the one described in Section |4~2| and was 
carried out on a Galaxy S3. We stress that we did not 
interact with the participants for the duration of the setup 
protocol. Participants were also asked to fill in a post¬ 
test questionnaire to evaluate the procedure they had just 
completed. 

Results. 37% participants were males and 63% were 
females. Most of them had completed a university degree 
(73%), and were aged between 24 and 35 (80%). 

All participants in group A managed to complete the 
task successfully. All participants of group B aborted 
the setup procedure because they detected a mismatch 
between the PIN displayed by the banking application 
and the one in the letter from the bank. 40% percent 
of the participants in group C failed to detect the missing 
PIN and completed the setup process, thereby leaking the 
indicator to the phishing application. 

The post-test questionnaire revealed that 91% of the 
participants rated the instruction sheet easy to understand 
(Ql) and 94% of them rated the task easy to complete 
(Q2). 85% of the participants believed that they had 
completed the task successfully (Q3) and 67% of them 
would use the mechanism in a mobile banking applica¬ 
tion (Q4). Figure[8]shows the distribution of the answers. 
Appendix |B] provides the full text of items Q1-Q4. 
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Response ^Strongly disagreej Disagree Neither agree nor disagreeHAgreeHstrongly agree 


Figure 8: Answers to the post-test questionnaire for 
the user study on the indicator setup protocol. Per¬ 
centages on the left side include participants that an¬ 
swered “Strongly disagree” or “Disagree”. Percentages 
in the middle account for participants that answered “Nor 
agree, nor disagree”. Percentages on the right side in¬ 
clude participants that answered “Agree” or “Strongly 
agree”. 


Our study suggests that the setup procedure was sim¬ 
ple enough to be completed by average users. Regarding 
attack detection, the “missing PIN” attack was the only 
one that went undetected. Participants may have judged 
the absence of the PIN as a temporary bug and decided 
to continue with the setup protocol. Similarly to what 
we have reported in Section |3.4| this result shows that 
users are acquainted with software bugs and are likely to 
tolerate a temporary bug even during a security-sensitive 
operation. Nevertheless, the user study reveals that our 
solution is usable and effective. 


5 Related Work 


Application phishing. Application phishing attacks 
have been described in recent research (5J2HHU an d 
several attacks have been reported in the wild (SJ TO|34) . 
Proposed solutions are primarily ad-hoc, i.e., they iden¬ 
tify specific attacks and try to prevent them by re¬ 
stricting the device functionality that those attacks ex¬ 
ploit (5 17 42). Personalized security indicators are a 
well-known concept from the context of website phish¬ 
ing and can provide an holistic solution to application 
phishing attacks in mobile platforms. Similar to previ¬ 
ous work on website phishing, the authors of (42) assume 
that the adversary cannot mount a phishing attack when 
the indicator is set up. In this paper we described a pro¬ 
tocol that allows the secure setup of personalized indica¬ 
tors in presence of an adversary. We are not aware of any 
previous work that provides the same security property. 


Web phishing. Anti-phishing techniques for the web 
have been deployed in practice 0G9- Proposals in¬ 
clude automated comparison of website URLs j27j, vi¬ 
sual comparison of website contents j4j43l, use of a sep¬ 
arate and trusted authentication device ||30|l, personalized 
indicators (6|20[33| , multi-stage authentication |T4) , and 
attention key sequences to trigger security checks on 
websites ED- While some of these mechanisms are spe¬ 
cific to the web environment, others could be adapted 
also for mobile application phishing detection. Website 
phishing in the context of mobile web browsers has been 
studied in (29p2) . 

Effectiveness of Security Indicators Previous research 
on the effectiveness of security indicators has mostly fo¬ 
cused on phishing on the web. Studies in this context 
have shown that users tend to ignore security indicators 
such as personalized images |20p3) or toolbars HMD- 
Browser warnings have been evaluated positively in a 
recent work (TJ, even if previous studies suggest other¬ 
wise mm- 

Mobile malware. Malicious mobile applications typi¬ 
cally exploit platform vulnerabilities (e.g., for privilege 
escalation) or use system APIs that provide access to 
sensitive user data. A malicious application can, for ex¬ 
ample, leak the user location or send SMS messages to 
premium numbers without user consent. For reviews 
on mobile malware, we refer the reader to recent sur¬ 
veys |11(|44|. Infection rates of mobile malware are re¬ 
ported in |38[ . 

Mobile malware detection is typically based on the 
analysis of system call patterns and detection of known 
platform exploits. The authors of (22) propose to de¬ 
tect malware by analyzing network traffic patterns. The 
detection mechanisms used for mobile malware are ill- 
suited for detection of mobile phishing applications, as 
many phishing attacks do not exploit any platform vul¬ 
nerability, do not require access to security-sensitive sys¬ 
tem APIs, and do not generate predictable network traffic 
patterns. 

6 Conclusion 

We have shown that personalized indicators can help 
users to detect application phishing attacks in mobile 
platforms and have very little deployment cost. We have 
conducted a large-scale (221 participants) user study and 
have found that a significant number of participants that 
used personalized security indicators were able to de¬ 
tect phishing. All participants that did not use indicators 
could not detect the attack and entered their credentials 
to a phishing application. Based on these results we con¬ 
clude that personalized indicators can help phishing de¬ 
tection in mobile applications and their reputation as an 
anti-phishing mechanism should be reconsidered. 
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We have also proposed a novel protocol to setup per¬ 
sonalized security indicators that does not rely on the 
“trust of first use assumption”. Our protocol allows users 
to securely setup the indicator, despite phishing software 
on the device. We have reported details on the imple¬ 
mentation of the setup protocol and have evaluated its 
usability. 
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Q4 lam more concerned about the secrecy of my mobile 
banking password compared to my email account 
password 

Q5 During the study, I have made sure that my personal 
image was showing before entering my username 
and password 

Q6 The login mechanism using personal images was in¬ 
tuitive and user-friendly 

Q7 I would use personal images in other applications 

B Post-test Questionnaire II 

We report the items of the post-test questionnaire for the 

user study on the indicator setup protocol (Section [4]). 

All items were answered with a 5-point Likert-scale from 

Strongly Disagree to Strongly Agree. 

Q1 The instruction sheet was clear and easy to under¬ 
stand 

Q2 The task was easy to complete 

Q3 I believe that I have successfully completed the task 

Q4 I would use this mechanism to improve the security 
of my mobile banking application 


Appendix 

A Post-test Questionnaire I 

We report the items of the post-test questionnaire for the 
user study on the effectiveness of personalized indicators 
(Section [3]). Items Q1-Q4 were answered by all partici¬ 
pants. Items Q5-Q7 were answered only by participants 
in the experimental groups (B, C, and D). All items were 
answered with a 5-point Likert-scale from Strongly Dis¬ 
agree to Strongly Agree. 

Ql I am concerned about malware on my smartphone 

Q2 I am concerned about the secrecy of my password 
for mobile banking 

Q3 I am concerned about the secrecy of my password 
for my email account 
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